> Second question: How can I write a program that keeps the LD_LIBRARY_PATH > variable from being exploited? i.e. the SUN 'login' bug where LD_LIBRARY_PATH > got exploited. I would ASSUME I could prevent this by doing something like: > putenv("LD_LIBRARY_PATH"), but that just seems too simple to be a true fix. A better solution is to smash the _entire_ environment flat, except for specific ones, such as TZ, that can be reasonably assumed to be safe (I hope - anyone broken into a system with the TZ variable? :-) You can never be sure what new undocumented environment variables exist that could be a security hole. ObBugDetectingHint: (I thought this to be obvious, but I've mentioned it to a few people who hadnt realised it, so may as well send it on) You can get an idea for whether a program is doing something stupid like a system() or popen() with 'strings'. For example, something like /bin/mail %s is usually a bit of a giveaway that someone is doing something stupid, and you might be able to break it. (bonus points if you can spot the program that the above is from :-) Anthony